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(57) Abstract: A data processing system for processing loan data comprises acquisition logic, reporting logic, and financial asset 
generation logic. The acquisition logic is configured to receive information pertaining to loan term, interest rate, principal owed 
and other parameters for a plurality of loans. The reporting logic is configured to receive payment information regarding borrower 
payments in connection with the plurality of loans. The financial asset generation logic is configured to facilitate creation and main- 
ly tenance of a plurality of financial assets backed by the plurality of loans. The acquisition logic, the reporting logic, and the financial 
asset generation logic are provided on a common integrated data processing platform. 
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SYSTEM AND METHOD FOR PROCESSING DATA 
PERTAINING TO FINANCIAL ASSETS 

BACKGROUND OF THE INVENTION 

FIELD OF THE INVENTION 

[0001] This invention relates to computer systems and methods used to 
process data pertaining to financial assets, such as loans, securities, and so 
on. 

DESCRIPTION OF RELATED ART 

[0002] The introduction of the mortgage backed security (MBS) has made 
the dream of owning a home possible for a much larger number of individuals. 
Frequently, when a borrower takes out a loan to purchase a home, that loan is 
subsequently pooled with other loans and used to create an MBS. The MBS is 
an investment instrument that can be sold to investors on Wall Street. Upon 
sale of the MBS, lenders can turn around and make new loans using proceeds 
from the sale. In effect, the MBS is a way for Wall Street to provide capital for 
loans to fund home ownership. The increased availability of capital reduces 
interest rates as compared to the interest rates that would otherwise be 
available, and therefore makes home ownership more affordable for an 
increased number of individuals. 

[0003] While the mortgage backed security approach has worked 
exceptionally well, home ownership rates could be further improved if loans 
could be used to create new forms of mortgage backed securities and/or other 
types of investment instruments or other assets that more optimally align with 
investor needs. A more optimal alignment would result in further increases in 
the availability of capital, further reductions in interest rates, and ultimately 
increased home ownership rates. 
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[0004] In addition to providing new types of investment instruments, it is 
also desirable to provide new types of loan products. Different borrowers are 
in different financial situations and have different financial needs. Providing 
new types of loan products to meet these needs is a further way of increasing 
home ownership rates. Some of these new loan products may not coincide 
with the current structure for mortgage backed securities. Often, users of the 
current structure must balance between the interests of borrowers and the 
interests of investors. A more flexible structure for the creation and 
maintenance of mortgage backed securities is needed. 

[0005] Efforts to offer new types of investment instruments and new types 
of loan products have been hampered by the fact that current data processing 
systems for processing loan information (including information on both the 
borrower side and on the investor side of the process) are not sufficiently 
efficient and flexible. Modifying the data processing system to support a new 
type of loan product or a new type of investment instrument is very difficult 
and expensive. In many cases, inherent limitations in the architecture of such 
data processing systems make certain types of new loan products or new 
investment instruments impossible to offer as a practical matter. 

[0006] Therefore, a need exists for computer systems and methods that are 
capable of providing increased flexibility in processing data pertaining to 
financial instruments and other financial assets. 

SUMMARY OF THE INVENTION 

[0007] According to a first preferred embodiment, a data processing system 
comprises acquisition logic, reporting logic, and securitization logic. The 
acquisition logic is configured to receive information pertaining to loan term, 
interest rate, principal owed and other parameters for a plurality of loans. The 
reporting logic is configured to receive payment information regarding borrower 
payments in connection with the plurality of loans. The securitization logic is 
configured to facilitate creation and maintenance of a plurality of financial 
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instruments backed by the plurality of loans. The acquisition logic, the 
reporting logic, and the securitization logic are provided on a common 
integrated data processing platform. 

[0008] According to a second preferred embodiment a data processing 
system for processing loan information comprises acquisition logic, reporting 
logic, securitization logic, and a rules engine. The acquisition logic is 
configured to receive acquisition information pertaining to loan term, interest 
rate, principal owed and other parameters for a plurality of loans. The 
reporting logic is configured to receive payment reporting information regarding 
borrower payments in connection with the plurality of loans. The securitization 
logic is configured to facilitate creation and maintenance of a plurality of 
financial instruments backed by the plurality of loans. The creation and 
maintenance of the plurality of financial instruments results in the generation of 
investment information. The loan information that is processed by the data 
processing system includes the acquisition information, the reporting 
information, and the investment information. The rules engine comprises a 
series of business rules and processes the loan information by applying the 
business rules to the loan information. 

[0009] Other features and advantages of the present invention will become 
apparent to those skilled in the art from the following detailed description and 
accompanying drawings. It should be understood, however, that the detailed 
description and specific examples, while indicating preferred embodiments of 
the present invention, are given by way of illustration and not limitation. Many 
modifications and changes within the scope of the present invention may be 
made without departing from the spirit thereof, and the invention includes all 
such modifications. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] Fig. 1 is a block diagram of a data processing system according to 
one preferred embodiment; 
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[001 1] Fig. 2 is a block diagram showing user services logic of the system of 
Fig. 1 in greater detail; 

[0012] Figs. 3A-3B are block diagrams showing underwriting logic, 
acquisition logic, servicer and investor reporting logic, and securitization logic 
of the system of Fig. 1 in greater detail; 

[0013] Fig. 4 is a block diagram showing common services logic of Fig. 1 in 
greater detail; and 

[0014] Fig. 5 is an exemplary data map used in connection with packeting 
logic in the system of Fig 1 . 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0015] Referring now to Fig. 1, a computer system 10 for processing data 
pertaining to financial assets is shown. As shown in Fig. 1, the system 10 
comprises a data processing system 12, user systems 14, bulk data systems 
16, and other data interfaces 18. The data processing system 12 further 
comprises user services logic 22, a transaction exchange processor 24, 
underwriting logic 26, acquisition logic 28, servicer and investor reporting logic 
30, securitization logic 32, common services logic 34, a data storage system 
38, and other data interfaces 36. Herein, although the term "logic" is used in 
connection with some blocks and the term "processor" is used in connection 
with other blocks, these two terms are used interchangeably. The term 
"processor" is used in the generic sense and is not meant to imply a separate 
discrete unit of processing hardware. 

[0016] The data processing system 1 2 is configured for processing data 
pertaining to financial assets, such as loans and securities. In one 
embodiment, the data processing system 1 2 is configured to be used by a 
participant in the secondary mortgage market. Herein, for convenience, the 
participant is referred to as a "purchaser," although it should be understood 
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that the purchaser may participate in the secondary market in other, different, 
or additional ways (e.g., as a loan guarantor, as a loan securitizer, and so on). 

[0017] The data processing system 12 is preferably usable to support 
various types of transactions which may be executed by such a purchaser in 
connection with one or more loans. For example, the purchaser may purchase 
loans from lenders or other loan originators as part of a cash execution. The 
purchased loans may, for example, be held as investments in the purchaser's 
investment portfolio. Alternatively, the purchaser may create mortgage backed 
securities (MBS) as part of an MBS execution, or create other financial 
instruments or assets that are collaterallized by cash flows associated with 
individual loans, including both loans that have been purchased by the 
purchaser and other loans that have not been purchased by the purchaser. For 
example, in the case of MBS, the purchaser may acquire a pool of loans, 
securitize the pool of loans to create MBS that is then sold to investors, and 
hold the pool of loans in trust for the benefit of the investors. The purchaser 
may also receive a fee for guaranteeing to holders of MBS or other financial 
instruments the repayment of the loans by borrowers. The purchaser may also 
use loans to create other types of financial assets or instruments, for example, 
by purchasing loans and selling the financial instruments to investors, or by 
performing such services for other owners of loan assets. 

[0018] The acquisition logic 28 is preferably usable to perform such 
operations as receiving information such as loan term, interest rate, principal 
owed and other parameters regarding loans when loans are first purchased or 
otherwise acquired and entered into the data processing system 12. In the 
case of cash executions, the acquisition logic 28 is also used to perform such 
operations as receiving commitments for the purchased loans. 

[0019] The servicer and investor reporting logic 30 is used to process 
periodic loan data for loan accounting purposes and generate accounting 
output in connection with the purchased loans. Herein, the terms "reporting 
logic" and "servicer and investor reporting logic" are used interchangeably and 
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both refer to logic that is configured to perform loan accounting and generate 
accounting output (e.g., for purposes of investor reporting, for purposes of 
managing a loan portfolio, and so on) in connection with a plurality of loans. 
The servicer and investor reporting logic 30 preferably performs such functions 
as receiving loan payment data on an ongoing basis from third party servicers. 
In this regard, it may be noted that the servicer and investor reporting logic 30 
in the illustrated embodiment is not used for servicing loans directly but rather 
interfaces with a third party servicer. Of course, the servicer and investor 
reporting logic 30 could also be configured to include additional logic for 
servicing loans, either as part of the servicer and investor reporting logic 30 or 
as part of another functional block. The accounting output generated by the 
servicer and investor reporting logic 30 may include such things as accounting, 
tax, performance/valuation, and/or other relevant financial information for the 
loans retained in the portfolio or sold, in whole or in part. 

[0020] The securitization logic 32 is used to generate financial assets. 
Herein, the terms "financial asset generation logic" and "securitization logic" 
are used interchangeably and refer to any logic that is used to generate/create 
financial assets. Herein, the term "financial asset" is used generically to refer 
to any asset that is backed by one or more cash flows, and includes such 
things as assets that are created entirely for internal data tracking purposes 
(e.g., in the case of packets which do not represent securities), as well as 
assets that have external significance (e.g., in the case of MBS or other 
security). The securitization logic 32 may be used to generate financial assets 
such as MBS or assets that are tracked internally in situations where the 
owner/operator of the data processing system 1 2 purchases a pool of loans 
and holds the loans as an investment in its own portfolio. 

[0021] It will be appreciated that the data processing system 1 2 may 
perform fewer or additional functions as compared to those described herein. 
For example, an entity that performs only some of the above-mentioned 
processes may use a computer system that contains only a subset of the 
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functions described herein. Herein, it will be assumed that the data processing 
system 1 2 is used to support each of the business processes described above. 

[0022] Generally speaking, in the illustrated embodiment, there are three 
access points for external systems into the data processing system 1 2. 
Access can include data flow into and out of system 1 2. A first access point 
into the data processing system 1 2 is the user services logic 22 which 
provides entry to the user systems 14. A preferred implementation of the user 
services logic 22 is described in greater detail below in connection with Fig. 2. 
For purposes of explanation, the user systems 1 4 are assumed to be operated 
by human users that participate in some way in the above mentioned business 
processes. For example, the human user may be an employee of a lender or 
other loan originator that uploads loan information to the purchaser (or 
corrects, updates, and so on, information that has previously been provided) in 
connection with committing to deliver or actually delivering a group of loans to 
the purchaser, an employee of an owner of a portfolio of loans that uploads 
loan information in connection with a group of loans the owner wishes to have 
securitized by the purchaser, an employee of a servicer that uploads payment 
information regarding a group of loans serviced by the servicer, an employee of 
an institutional investor that downloads information regarding the financial 
performance or other data regarding investment instruments created and 
maintained by the purchaser, an employee of the purchaser itself, and so on. 

[0023] A second access point into the data processing system 1 2 is the 
transaction exchange processor 24 which provides entry to the bulk data 
systems 16. The transaction exchange processor provides an alternative, bulk 
transfer mechanism for exchanging at least some of the transaction-related 
data mentioned above in connection with the user systems 14, typically 
without intervention of a human operator. Such bulk data transfers may occur 
with lenders, servicers, and so on. The transaction exchange processor 24 
receives/sends transactions, and prescreens/sorts/translates data if needed, 
and makes the transactions/data available for further processing in the data 
processing system 1 2 or outbound transmission. A third access point into the 
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data processing system 1 2 is through the data interfaces 1 8. The data 
interfaces 1 8 may be used to exchange other types of data between other 
computer systems and the data processing system 1 2. For example, the data 
interfaces 1 8 may be used to import or export data to other external computer 
systems (that is, computer systems not under the control of the purchaser) or 
other internal computer systems (e.g., computer systems that are under the 
control of the purchaser but that provide functionality that is not integrated 
into the data processing system 12). 

[0024] The data processing system 1 2 is described in greater detail below in 
connection with Figs. 2-5. As will become apparent from the discussion 
below, the preferred data processing system 1 2 exhibits a high level of data, 
service and time granularity. With respect to data granularity, the system 1 2 is 
capable of decomposing loans into a series of highly granular cash flows and 
tracking all of the cash flows from the point the cash flows enter the data 
processing system 1 2 (e.g., as part of a loan payment or other cash flow 
source) to the point the cash flows exit the data processing system 1 2 (e.g., 
as part of a payment on a financial instrument). The decomposition of a 
particular loan into sub-loan cash flows may occur when the loan is first 
acquired, later when servicing activity begins on the loan, or at another time. 
When loan payments are received, the allocation of the loan payment into 
individual cash flows may be performed by logic executed by the servicer, by 
the data processing system 12, or by other logic. Ideally, all or nearly all of the 
cash flow sources associated with a particular loan can be identified and 
tracked. Additionally, it is also possible to aggregate cash flows from a 
borrower perspective or other entity perspective. For example, a series of loans 
(e.g., all to the same borrower) may be aggregated into a higher order cash 
flow and then the aggregation of the loans may be decomposed. It is also 
possible to add cash flows to existing loans, for example, so that a new cash 
flow (e.g., for a new line of credit) may be established without having to set 
up a new loan. This provides additional flexibility to modify a borrower's loan 
over time., Thus, the data processing system 1 2 not only decomposes and 
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maps cash flows associated with such things as principal and borrower paid 
interest, but also sub-loan level cash flows arising in association with the 
borrower paid interest or fees associated with the loan such as servicing fees, 
guarantee fees, mortgage insurance, prepayment penalties, borrower-paid fees, 
servicer advances, servicer recoveries, and loss/default components, and 
provides other flexibility. Additional description regarding exemplary possible 
sources of cash flqws is provided at the end of this section. The 
decomposition and mapping of cash flows dramatically increases the number of 
different types of financial instruments that may be created, because it makes 
it possible to create financial instruments based on these other cash flows. In 
turn, this makes it possible to create financial instruments that are more 
optimally configured to meet the needs of the owner of the financial 
instrument. 

[0025] With respect to service granularity,. the data processing system 12 
represents loans as a series of attributes and uses a business rules engine to 
process loan information. This dramatically simplifies the process of expanding 
the capabilities of the data processing system 1 2 to process data associated 
with any type of loan. The capability to process a new type of loan may be 
added by adding an additional attribute to a list of attributes corresponding to 
the new product feature (or modifying existing attributes), by using the 
attribute to indicate the presence or absence (and/or other characteristics) of 
the new feature in a particular loan, and by modifying the rules engine to 
incorporate additional rules regarding the new loan feature. It is not necessary 
to build a completely new data processing system for the new type of loan. 
This makes it easier to offer new types of loans which are more optimally 
configured to meet the needs of individual borrowers. An exemplary set of 
attributes is described at the end of this section. 

[0026] With respect to time granularity, the data processing system 1 2 is 
capable of processing data using a much smaller time slice or update period 
than has been possible in the past. In the past, systems have typically been 
constructed around the assumption that servicers provide monthly reports 
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which summarize loan activity that occurred during the previous month. The 
time slice for reporting has been one month and sub-monthly temporal data has 
been lost. In the data processing system 12, when information regarding new 
loans is received by the acquisition logic 28 and/or when information regarding 
loan payments is received by the servicer and investor reporting logic 30, this 
information preferably includes information regarding the date the loan was 
acquired, the date or dates within each month or other period other period on 
which a payment or other transaction is expected, and/or the date the payment 
was received. The time slice in the data processing system 1 2 is therefore one 
day (or less, if a smaller time slice such as AM/PM, hour, minutes, seconds, 
and so on, is used). The temporal information is stored and maintained in 
databases which are synchronized/commonly accessible by the acquisition 
logic 28, the servicer and investor reporting logic 30, and the securitization 
logic 32. As a result, the acquisition logic 28, the servicer and investor 
reporting logic 30, and the securitization logic 32 each have access to this 
highly granular temporal information regarding loan acquisitions and payments. 
The increased time granularity supports the above-mentioned capabilities to 
offer a wider array of loans to borrowers and a wider array of financial 
instruments to investors. For example, the increased time granularity 
facilitates offering loan products in which the borrower is expected to make bi- 
weekly payments, which may be attractive to borrowers that get paid bi- 
weekly instead of twice-monthly or monthly. This also facilitates handling loan 
products in which the date of a transaction is meaningful, such as daily simple 
interest loans. Further, because sub-loan cash flows can be processed using a 
one day time slice (or less), it is possible to create financial instruments based 
on cash flows that are processed on a per day basis. 

[0027] Another benefit of the acquisition logic 28, the servicer and investor 
reporting logic 30, and the securitization logic 32 being provided on a common 
platform and having access to common/synchronized databases is that each 
system has an up to date view of the data. As previously indicated, the data 
processing system 1 2 has the ability to accept payment and other transaction 
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information from a servicer as such transactions occur (e.g., using daily, 
hourly, or near real-time updates) instead of or in addition to receiving end of 
the month summary transaction information from the servicer. Once the data 
is received, it is accessible throughout the data processing system 12. For 
example, it is not necessary to limit the data updates for the securitization logic 
to a once-per-month basis at the end of a servicing cycle. Therefore, an up to 
date view of the data is available throughout the data processing system 12. 

[0028] It should be apparent that it is also possible to construct data 
processing systems which do not incorporate the advantages described herein 
in connection with the data processing system 1 2, or which also incorporate 
additional advantages not described herein. Further, it may also be noted that 
the separation of functionality shown in Figs. 1-4 is necessarily to some extent 
conceptual, and it is also possible to provide the same functionality in other 
ways. Additionally, although numerous functions are described below, it may 
be noted that it may be desirable to provide fewer, additional, or different 
functions in a given data processing system depending on the application and 
what is needed. 

[0029] Referring now to Fig. 2, a preferred implementation of the user 
services logic 22 and subcomponents thereof will now be described. The user 
services logic 22 includes electronic registration logic 50, access and security 
logic 52, user experience logic 54, report request processing logic 62, and a 
notification processor 64. The registration logic 50 is used to register 
individual users to be able to use the data processing system 12. For example, 
an employee of a lender may be given a login name and password to access 
the data processing system 1 2. User registration preferably includes providing 
each user with an authorization profile that defines the extent and type of 
access the user is given to the data processing system 1 2 and the types of 
operations that the user may perform while accessing the data processing 
system 12. The access and security logic 52 cooperates with the electronic 
registration logic 50 to permit users to access the data processing system 12 
in the manner authorized. 

li 
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[0030] The user experience logic 54 provides a user interface to the data 
processing system 1 2. Preferably, the user accesses the data processing 
system 12 through the Internet or an Intranet by using a personal/laptop 
computer or other suitable Internet-enabled device. For example, the data 
processing system 1 2 may be accessible to users by visiting the purchaser's 
web site (that is, the web site of the entity that owns/operates the data 
processing system 1 2, and that is assumed to be in the business of 
purchasing, guaranteeing, and/or securitizing loans) and clicking on appropriate 
links located at the web site. Depending on the authorizations the user has 
been given in the registration logic 50, the user is able to access different web 
pages of the web site relating to the underwriting logic 26, the acquisition logic 
28, the servicer and investor reporting logic 30, and the securitization logic 32. 
For example, there may be one or more web pages relating to acquisitions that 
may be accessed by lenders, one or more pages relating to servicing that may 
be accessed by servicers, and so on. The user may then perform functions in 
accordance with what is permitted by the user's authorization profile (which, in 
turn, is typically based on the user's employer and the user's job function for 
that employer). For example, an employee of a lender may be given 
authorization to access web pages associated with the acquisition logic 28 and 
commit the lender to deliver a quantity of loans on a future date (i.e., to 
engage in a forward commitment with the purchaser). The types of operations 
that different users may perform is described in greater detail in connection 
with Figs. 3A, 3B and 4 below. 

[0031] The user experience logic 54 includes business application 
components 56, reference data 58, and user help logic 60. These components 
provide implementation support to the above-described user interface. The 
business application components 56 includes logic that assists directing the 
user to the correct web page. The reference data 58 may include data 
regarding user preferences for the appearance of web pages to the user. The 
reference data 58 may also provide general reference data and content that 
assists user interaction with the web site. The reference data 58 may also 
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include data regarding particular lenders, such as the year the lender was first 
approved to do business with the purchaser, contact information for the lender, 
and performance information such as statistics and transfer history for the 
lender. The user help logic 60 provides other help or "How To" components. 

[0032] The user services logic 22 also includes report request processing 
logic 62 and a notification processor 64. The report request processing logic 
62 permits lenders and servicers to access the data processing system 1 2 and 
request reports generated from the data the lenders or servicers have provided 
the purchaser. The reports may be predefined "canned" reports, or may be 
ad hoc reports defined by the user by drilling down into the data and/or 
defining data filters. The type of reporting generation capability available may 
be made dependent on the type of user. The report request processing logic 
62 may be used for incoming data in connection with lenders and servicers 
and/or for outgoing data in connection with investor reporting. Investor 
reporting may also be handled by other logic described below. 

[0033] The notification processor 64 sends notifications/alerts to users. For 
example, the notification processor 64 may be used to send e-mail (or fax, 
automated telephone call, and so on) to a user associated with a servicer or 
lender indicating that data which has been submitted by the servicer or lender 
has been processed, and that the processed data is ready for review. The 
notification processor 64 is useful in the context of exceptions processing, 
when lender/servicer data is processed but the processing indicates that there 
may be an error in the lender's/servicer's data which requires review by a 
human operator. 

[0034] Referring now to Fig. 3A, a preferred implementation of the 
underwriting logic 26 and subcomponents thereof will now be described. The 
underwriting logic 26 is typically accessed by users that originate loans, such 
as lenders and brokers. The underwriting logic 26 includes data capture logic 
70, underwriting logic 74, and credit scoring logic 72. The data capture logic 
70 is used to receive information to be used in loan underwriting and appraisal 
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(e.g., information from a loan application and a credit report). Typically, the 
information that is received for loan underwriting is a subset of the information 
that would be provided on a loan application. The credit scoring logic 72 and 
the underwriting logic 74 cooperate to analyze the information to determine if 
the loan meets credit risk and eligibility requirements of the purchaser, and 
then issue a recommendation based on the assessment of the overall risk 
profile of the loan. The credit scoring logic 72 generates a credit score of the 
loan applicant based on the loan applicant's credit history. The underwriting 
logic 74 then combines the credit score with other information (e.g., debt-to- 
income ratios, appraisal value, income verification, borrower contribution, cash 
reserves of the borrower, the existence and amount of subordinate financing, 
and other factors) to determine whether to approve loan eligibility. The 
underwriting logic 26 may also be used to generate reports that provide 
information regarding the underwriting recommendation for a particular loan, 
information used in determining the recommendation (e.g., property, loan, and 
borrower information), and information summarizing key statistics from the 
credit report (e.g., borrower's open accounts, derogatory accounts, and 
undisclosed accounts). 

[0035] Still referring to Fig. 3A, a preferred implementation of the acquisition 
logic 28 and subcomponents thereof will now be described. The acquisition 
logic 28 further includes cash committing logic 80, deal management logic 82, 
lender eligibility logic 84, pricing logic 86, delivery logic 88, certification logic 
90, and custody logic 92. 

[0036] The cash committing logic 80 provides a facility for performing all 
cash commitment functions. Typically, a master agreement/contract may be in 
place between the purchaser and the lender which defines overall terms of loan 
sales to the purchaser pursuant to particular commitments. A cash 
commitment is an agreement (typically, governed by the overall master 
agreement) in which the mortgage purchaser agrees to buy mortgages from 
mortgage sellers (e.g., lenders) in exchange for a specified price in cash. 
Typically, a cash commitment agreement specifies the type of mortgage(s) the 

14 



WO 2004/061558 



PCT/US2003/037176 



seller plans to deliver, the amount of time the seller has to make delivery, the 
price the mortgage purchaser will pay the seller for the loan(s), other pertinent 
loan terms, and, in some cases, loan level details pertaining to the mortgage. 

[0037] The cash committing logic 80 provides a central point for approved 
lenders (or other approved sellers) and the purchaser to perform all cash 
commitment functions. These functions may include, for example, making 
standard forward commitments, handling pair-off of commitments, extending 
commitments, over-delivering of a commitment, maintaining configurable 
parameters, updating contact information, updating commitment records, 
viewing and selecting from a seller's favorite product list, adding to and 
maintaining the seller's favorite product list, viewing contracts, fees, prices, 
price adjustments, and so on. As previously described, the access and security 
logic 52 verifies the identity of the user (using a login ID and password) and 
allows the user to gain access to the cash committing logic 80. Different types 
of users may be granted different levels of access to the cash commitment 
logic 80 (e.g., for different employees within a seller organization having 
different levels of authority to act on behalf of the seller). 

[0038] In the preferred embodiment, the system 1 2 includes the ability to 
limit the different types of loans that a given seller may sell to a subset of the 
loans which the purchaser may purchase. The different products may 
comprise loans of different terms, different interest rates and types of interest 
rates (fixed or variable), as well as a variety of other features or combinations 
of features that may be offered in connection with the particular mortgage 
products. This information may be stored in the lender eligibility logic 84, 
described below, and the cash committing logic 80 may interface with the 
lender eligibility logic 84 to limit commitment activity to only those products 
that the seller is eligible to sell. During the committing process, the seller 
selects the type of product the seller plans to deliver from a list of eligible 
products. Sellers may be provided the ability to flag any eligible product as a 
"favorite," and are able to select products from a favorites list when making 
commitments. Preferably, sellers are also provided with the option to assign 
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their own marketing name for each eligible product in the seller's favorites list. 
In another embodiment, rather than selecting from a list of eligible products, 
sellers may be provided the ability to define a product they plan to deliver by 
defining the loan attributes. 

[0039] The committing logic 80 provides sellers with the option to apply a 
commitment to a master agreement. Information regarding master agreements 
is supplied by the deal management logic 82 and displayed in the cash 
committing logic 80 for a given seller. The display may, for example, indicate 
valid master agreement numbers, the unfulfilled commitment amount in dollars 
for each master agreement, the expiration date for each master agreement, 
and/or other pertinent information. 

[0040] The deal management logic 82 is used to store and track terms of the 
deals/contracts made between sellers of loans and the purchaser. When a 
seller contacts the purchaser to initiate negotiation of a new deal, an employee 
or other representative of the purchaser uses the deal management logic 82 to 
create a master agreement, MBS pool contract and all the associated 
variances. 

[0041] During the master agreement negotiation process, all terms and 
stipulations of the agreement are entered into the deal management logic 82. 
The deal management logic 82 enables authorized users creating or modifying 
variances to identify editable variances and facilitates transforming "codeable" 
variances into business rules in the delivery logic. The deal management logic 
82 also facilitates communication of these variances to users responsible for 
analyzing them. Users responsible for analyzing variances are provided a link 
to the edit engine where they are able to add, modify, or delete edits based on 
their analyses. 

[0042] The deal management logic 82 also integrates with the pricing logic 
86 so that loan level price adjustments that reflect negotiated variances may 
be entered and displayed in the generated master agreement. The seller's 
specific adjustment tables (referencing master agreement and variance 
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reference numbers) may also be stored in the deal management logic or, more 
preferably, in the lender eligibility logic 84. 

[0043] The lender eligibility logic 84 is logic that maintains information 
regarding the eligibility of particular lenders to offer particular products made 
available by the purchaser. The lender eligibility logic 84 allows users (via web 
interface) to maintain and update product or lender-specific parameters in 
connection with the committing logic 80, the delivery logic 88, the certification 
logic 90, the custody logic 92, and the servicer and investor reporting logic 30. 
The lender eligibility logic 84 may also be used to set pricing incentive 
adjustments, other price adjustments, fees and other parameters at the lender 
and product levels. 

[0044] The pricing logic 86 is the logic used to generate pricing information 
and provide the pricing information to other logic in the data processing system 
1 2, including the underwriting logic 26, the committing logic 80, the delivery 
logic 88, the certification logic 90, the custody logic 92, and the servicer and 
investor reporting logic 30. For example, the pricing logic 86 may be accessed 
during delivery to determine the price to be paid for a particular loan, or after 
the loan is delivered to determine how changes/corrections in loan information 
affect pricing. The pricing logic 86 takes into account pricing elements such as 
commitment/interest price (based on interest and the type of commitment), 
commitment calculations (e.g., for price adjustments associated with pair-off s, 
over delivery, extensions), and credit adjustment price (based on loan level 
credit risk). In addition to cash pricing (i.e., pricing in situations where the loan 
is paid in cash), the pricing logic 86 may also be used for MBS pricing (i.e., 
pricing in situations where the loan is paid for using a mortgage backed 
security). The pricing elements related to a MBS include the guarantee fee, the 
buy-up/buy-down amount, and the credit adjustment amount. 

[0045] The pricing logic 86 interacts with the delivery logic 88 (described in 
greater detail below) when a seller is unable to fulfill the terms of its original 
commitment to generate price adjustments associated with pair-offs, over 
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delivery, and extensions. The pricing logic 86 acquires delivery and under 
delivery tolerance amounts from the lender eligibility logic 84, processes data 
from a commitment inventory database to locate expired commitments and 
under deliveries, based on input from the delivery logic. The pricing logic 86 
also processes data associated with the original commitment parameters to 
generate price adjustments. Additionally, price adjustments may also be 
assessed at the time of delivery for credit risk in connection with one or more 
loans that exceeds a pre-determined and agreed-upon level. In particular, at 
the time a cash commitment or MBS deal is made, a certain level of credit risk 
is assumed when determining the cash price or MBS guarantee fee. Later, 
when loans are actually delivered, the true risk level is identified. If the cash 
price or MBS guarantee fee does not account for this actual level of risk, a 
price adjustment is made. The system allows the option of selecting either an 
upfront loan level price adjustment at the time of delivery or a guarantee fee 
basis point adjustment to permit the payment to be made over time. 

[0046] The pricing logic 86 also interacts with the servicer and investor 
reporting logic 30 when there are loan level changes during the servicing of the 
loan that result in a request for pricing. The servicing logic 28 sends the 
pertinent data attributes needed for pricing to the pricing logic 28 and the 
pricing logic 86 returns pricing information for the loan in question. 

[0047] The pricing logic 86 may also be used to access prices set forth in 
pricing grids that store pricing information as a function of various loan 
parameters and/or features, e.g., interest rate and remaining term in connection 
with a particular seller. The pricing grids may be generated manually (e.g., in a 
spreadsheet which is provided to the pricing logic 86) or automatically. The 
pricing logic 86 may also be used to generate reports regarding pricing 
information. 

[0048] The delivery logic 88 is the logic used to process loans when loans 
are delivered to the purchaser in connection with a purchase. The delivery logic 
88 analyzes loan attributes, the associated deal/contract with the seller, and 
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execution parameters to determine if the loan is acceptable for submission 
under the terms and conditions of the deal. The delivery logic 88 also invokes 
the pricing logic 86 to determine the price and/or price adjustments associated 
with accepting the loan. The delivery logic 88 also allows sellers to set up 
pools in cases where the loans are pooled in MBS. 

[0049] The delivery logic 88 receives electronic loan data by way of the user 
services logic 22 or the transaction exchange processor 24. The purchaser will 
generally also receive paper loan documents that support the electronic loan 
data received by the data processing system 12. 

[0050] The delivery logic 88 utilizes aspects of the underwriting logic 26, 
the deal management logic 82, and the pricing logic 86. Each loan that is 
delivered is checked against business rules and data format rules. Business 
rules are based on the product, pool/piece/contract, pricing, commitment, and 
other factors. For example, a seller may inadvertently try to deliver a 1 5-yr 
loan in connection with a commitment for 30-yr loans, and the business rules 
provide a mechanism for identifying that the 1 5-yr loan can not be used to 
satisfy that commitment. The delivery logic 88 uses the notification processor 
64 to notify the seller when/if the data that is being delivered does not match 
the commitment. The delivery logic 88 also cooperates with the underwriting 
logic 26 to confirm that the loans that are being delivered meet underwriting 
criteria. Sellers are notified using the notification processor 64 when 
underwriting decisions for a particular loan is different than was anticipated 
based on the original (typically, incomplete or incorrect) loan data and there is 
an impact to the price that the seller will be charged. The pricing logic 86 is 
invoked to determine the change in price. 

[0051] The delivery logic 88 allows the user to edit the delivery data for 
format/field edits and standard/custom edits necessary to deliver loans to the 
purchaser. Users have a real time view of updates to the delivery data in order 
to resolve data errors before the loan is purchased or securitized. For example, 
if the data indicates that a 1 5-yr loan is being used to satisfy a commitment for 



19 



WO 2004/061558 



PCT/US2003/037176 



a 30-yr loan, the user may edit the data to indicate that the loan is a 30-yr loan 
(in a situation where the loan data was incorrectly entered and what was 
originally indicated as being a 1 5-yr loan is in fact a 30-yr loan). Alternatively, 
the user may edit the data to instead apply the 1 5-yr loan to a different 
commitment for a 1 5-yr loan. As a further alternative, the user may edit the 
data to substitute a 30-yr loan for the 1 5-yr loan. The delivery logic 88 also 
includes logic for address correction (detecting erroneous address information 
and correcting the address information) and geographic coding (to provide 
additional geographic information on the property, such as longitude and 
latitude, tract, congressional district, metropolitan statistical area number, and 
so on). By the end of the process, the delivery logic also generates a unique 
loan number for each of the loans for tracking purposes. 

[0052] The certification logic 90 is logic that supports the process of 
ensuring that all loan documentation is complete and legally binding and that 
the paper documentation matches the electronic information delivered by the 
seller. The certification logic 90 generates, stores and makes available to other 
aspects of the data processing system 1 2 information pertaining to which 
loans have been certified. The certification logic 90 is also able to generate 
custom reports regarding certification data including reports on loans that have 
not been certified so that appropriate action may be taken (e.g., having the 
seller repurchase the loan). The certification logic 90 facilitates data 
modification and facilitates data matching when loans are redelivered or 
resubmitted. The certification logic 90 also generates reports to support 
management decisions with respect to certification activities. 

[0053] The custody logic 92 is logic that is used to support the custody 
process, or the process whereby the purchaser stores the paper loan 
documents during the time from when the loans are purchased or securitized 
until they are released. Custody protects the physical evidence of investment 
in negotiable assets. The custody logic 92 manages custodial profile/contact 
information, custodian/seller relationships, and seller/servicer profile/eligibility 
information related to custody activities. The custody logic 92 also permits 
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information to be retrieved regarding loan investors. If the market purchaser 
performs the custody function itself rather than having a third party act as 
custodian, the custody logic 92 also supports document management in 
connection with incoming and outgoing documents. In particular, the custody 
logic 92 tracks when loan documents are in the possession of the purchaser 
and otherwise manages and monitors the position of the physical loan 
documents. The custody logic 92 also manages and calculates fees charged 
for custodial and certification services. 

[0054] The acquisition logic 28 may also include other logic in addition to 
the logic described above. For example, the acquisition logic 28 may further 
include payable/receivable manager logic to track the billing of price 
adjustments and fees generated by transactions in the committing logic 80, the 
pricing logic 86, the delivery logic 88, the custody logic 92, and certain 
aspects of the servicer and investor reporting logic 30. The payable/receivable 
manager logic may also be used to display the status (including payment 
status) of such price adjustments and fees in a consolidated manner. 

[0055] Referring now to Fig. 3B, a preferred implementation of the servicer 
and investor reporting logic 30 will now be described in greater detail. The 
servicer and investor reporting logic 30 includes loan process and compare 
(LPC) logic 100, which monitors and verifies the activities of third party 
mortgage servicers on an ongoing basis. Alternatively, if servicing is 
performed internally by the owner of the data processing system 1 2 and is 
included as part of the servicer and investor reporting logic 30 or as part of 
another functional block of the data processing system 1 2, the LPC logic 100 
may be used to verify internally generated reporting information. Thus, the 
LPC logic 100 performs such operations as receiving and validating reporting 
information pertaining to loan activity, loan delinquency information and unpaid 
balance comparison reported by the servicer, updating the records of the data 
processing system 100 regarding the status of all reported loans, and 
determining the remittance and disbursement amounts that are expected for 
the loans. 
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[0056] As an initial matter, prior to loan servicing, a comparison is performed 
of the servicer's data for loans being serviced with the purchaser's data for the 
same loans. Even if the purchaser's data has already been compared with 
lender data for the same group of loans, the servicer's data may for some 
reason be different. Accordingly, the purchaser may provide a predefined set 
of acquisition data to the servicer that the servicer can compare with the 
servicer's data. At any time thereafter, the servicer may perform individual 
queries of the loan data stored on the purchasers data base via the user 
services logic 22 (web interface) and download the data for further comparison 
purposes. When exceptions are noted, the servicer can correct its data or 
submit a change request via the user interface to the attribute change 
processor (ACP) logic 122, described below. 

[0057] During the life of the loan, when loan activity occurs (e.g., when the 
borrower makes loan payments), the LPC logic 100 is executed with regard to 
a particular loan when a servicer reports transactions to the purchaser. A loan 
activity processor 102 handles expected, and scheduled servicing transactions 
including payments, rate changes, curtailments, and so on. The activity 
processor 1 02 receives and validates loan transaction data, such as loan 
activity, unpaid balance comparison, and delinquency status updates. The 
activity processor 102 also can be configured to check for duplicate 
transactions, validate servicer information, determine and validate the type of 
loan transaction, and validate that the loan activity is being reported in the 
correct reporting period. The activity processor 102 also confirms that 
changes in unpaid balance and last paid installment are correct, derives 
expected interest remittance, derives expected principal remittance, and 
compares the derived amounts to the reported remittance amounts. After 
validation, the status of the loan is made available to the servicer through the 
user services logic 22. The activity processor 102 also triggers the appropriate 
cash and accounting transactions in a book and tax accounting processor 146. 
When loan activity is processed and does not match the purchasers 
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expectations based on rules and calculations, exceptions are noted and 
communicated to users using the notification processor 64. 

[0058] The amortization/calculation processor 1 04 is used by the activity 
processor 1 02 to calculate loan level amounts, such as principal and interest 
due, servicing fees and other data pertinent to each loan. Processor 104 may 
additionally be used to compute derived or decomposed cash flows, such as a 
guaranty fee or a servicing fee. Business rules are used to identify scheduled 
and unscheduled principal, calculate fees, calculate remittance and 
disbursement amounts, calculate amounts to be disbursed to investors, 
amortization, and accruals. These calculations are used throughout the system 
1 2 to perform functions such as collecting remittances from servicers, 
dispersing funds to investors and performing accounting activities. The results 
of processing are available through an interactive user interface to both 
personnel of the purchaser and personnel of the servicer for correction when 
transactions do not comply with business rules. 

[0059] The trial balance processor 106 provides for validation of parameters 
such as servicer number, purchaser and servicers loan numbers, effective date, 
ending unpaid balance, note rate, pass through rate, principal and interest 
payment, last paid installment (LPI) date, pool number, accrued interest 
receivable balance, available line of credit, conversion date, reverse mortgage 
payment, net principal limit, taxes and insurance set asides, property charges 
set asides, repairs set asides, servicing fees set asides, scheduled payments, 
and so on. Any discrepancies are resolved and any system updates (loan 
attribute changes, data updates) are implemented. The LPC logic 100 then 
reprocesses the activity based on the corrected data. 

[0060] In addition to borrower payments, the LPC logic 100 may also be 
triggered with regard to a particular loan when the attribute change processor 
(ACP) logic 122 makes a change to attributes that affect loan processing or 
when a loan attribute triggers processing, such as note rate changes, payment 
changes and loan reporting. The LPC logic 100 may also be triggered by 
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borrower behavior (e.g., loan delinquencies status) at beginning and end of 
accounting periods. 

[0061] The servicing event processor 108 identifies and handles business 
events that are not identified by the activity processor 102. Examples of these 
events include identifying delinquent loans and identifying loans that are 
eligible for reclassification or substitution. The delinquency status reporting 
processor 1 1 0 accepts delinquency reasons from the servicer for loans that 
have payments that are in arrears. 

[0062] The attribute change processor (ACP) logic 1 22 processes loan or 
security level changes. The ACP logic 122 processes attribute changes 
regarding loans. As previously described, in the preferred embodiments, loans 
are characterized in the data processing system 12 by a series of attributes 
rather than by product codes. Each mortgage product that is purchased is then 
represented by a series of attributes instead of or in addition to an overall 
product code. New products may be created by creating new combinations of 
attributes, or by adding new attributes. An exemplary list of possible attributes 
that may be used is provided at the end of this section. 

[0063] The ACP logic 1 22 processes attribute changes that occur after loans 
are brought into the data processing system 12. In particular, after loans are 
brought into the data processing system 12, the ACP logic 122 processes 
attribute changes that are unexpected or are unscheduled whereas the LPC 
logic 100 handles attribute changes that are both expected and scheduled. 
The ACP logic 1 22 also validates the attribute change request, assesses the 
financial impact of the change, updates the appropriate data and triggers the 
appropriate cash and accounting transactions. 

[0064] Unexpected attribute changes are changes that are required due to 
new features or discrepancies between contract documentation and data 
captured by the acquisition logic 26, this can include changes to loan data 
and/or changes in loan behavior. Unscheduled attribute changes are changes 
that may occur based on contract documentation but the timeframe is 
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unknown. For example, an unexpected attribute change would be a change for 
a daily simple interest cash loan that the purchaser has purchased without 
knowledge of a particular feature. After the purchase, the borrower exercises 
options under the feature and the servicer advances the next due date of the 
loan and submits a loan activity transaction record to the purchaser. Not 
knowing about the feature, the purchaser rejects the transaction since the loan 
record does not indicate the presence of the feature. After assessing the 
exception and evaluating the change, the servicer submits an attribute change 
request to add this feature and keep the loan in the purchaser's portfolio or in 
the security, pending confirmation of continued loan eligibility. An example of 
an unexpected and unscheduled attribute change would be the case where the 
lender submits an adjustable rate mortgage change request for a loan that the 
purchaser has set up as a fixed rate mortgage. The request is processed as an 
unscheduled change because the purchaser's systems have never had an event 
scheduled to trigger the change. An example of an unscheduled change is a 
fixed rate convertible loan which has the conversion option indicated in the 
terms of the note. It is anticipated that an attribute change will occur but the 
timing of the event is unknown and therefore unscheduled. The two primary 
types of unexpected attributed changes are post purchase adjustments (data 
corrections) and modifications (attribute changes driven by a number of 
business requirements, such as product flexibility, delinquency management, 
and substitutions/reclassif ications) . 

[0065] In operation, the ACP logic 1 22 receives attribute change requests 
which indicate current database values for the loan and the proposed changes. 
The validation of the loan with the new values is then accomplished by 
applying the rules processor 1 80 to the ACP transaction. The business rules 
engine is applied to determine whether the changes are allowable and any 
failed business rules are provided to an operator for further review. Next, the 
original terms of the contract are used to determine any pricing adjustments of 
the attribute change. The system determines the difference between the 
current or adjusted price as applicable and the new price for the purchase 
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adjustments. Next, a human operator reviews the requested change, the 
impact of the requested change, and any required hard copy documentation 
needed to justify the change. The operator/business analyst either approves or 
rejects the change. Rejected transactions may be modified and resubmitted. 
Approved adjustment transaction values are applied to the database and an 
audit trail history is maintained. If the result of the change request has an 

accounting impact, the ACP logic 1 22 also generates the appropriate 

i 

transactions to trigger the accounting processor 146. 

[0066] The ACP logic 1 22 also includes loan conversion request processing 
logic for handling loan conversion requests. Thus, when a loan conversion 
request is received, this logic tracks the request for the change, determines the 
allowability of the change based on business rules, and employs the remainder 
of the ACP logic 1 22 to make the change. 

[0067] The securities aggregation and management (SAM) logic 130 
receives the loan level cash flow information produced by the LPC logic 100 
and aggregates this cash flow information to produce security level 
information. The security level information is produced at each of the 
following levels: remittance/express date level within each piece/single pool; 
single pool level or piece level within each major pool; pseudo pool (pool-like 
reporting group) level; major header level for each major pool; choice pool level; 
strip level; mega pool level; and mega in mega (MIM) pool level. In addition to 
securities, the SAM logic 1 30 is also capable of processing and managing any 
grouping of loans, cash flows from loans, and other financial instruments. 
Using a packet activity processor 132, the SAM logic 130 determines the 
loans in a given pool, aggregates cash flows based on the pool and loan level 
attributes for all the loans and then updates the system database. The packet 
activity processor 1 32 has the flexibility to aggregate loan level cash flows at 
the most granular level to security level enabling the SAM logic to also manage 
specific cash flow strips (e.g., access yield strips, interest only strips). At the 
end of appropriate processing periods, the SAM logic 1 30 finalizes the relevant 
security information. The SAM logic 130 then uses a packet disclosure 
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processor 134 to make final remittance level principal and interest, guaranty 
fee, and other draft amounts available to a cash processing logic 144 and to 
make security accounting data available to a book and tax accounting logic 
146. The SAM logic 130 also calculates, at the various MBS security levels, 
disclosure data for investors and the payment distribution to investors. The 
SAM logic 130 also includes packet modification request processing logic 
which is used to modify packets in generally the same manner that the 
attributes of loans are modified as described above in connection with the ACP 
logic 122. The operation of the SAM logic 130, and in particular packets and 
the packet activity processor 132, is described in greater detail in connection 
with the packeting logic 1 54. 

[0068] Further, the SAM logic 1 30 can be used to facilitate the provision of 
real-time data updating. For example, investors may be supplied with real-time 
analytic data. The analytic data may include any data that allows investors to 
more accurately determine the value of their holdings, such as data concerning 
monthly loan payments, loan prepayments, loan pay-offs, and so on. For 
example, when a loan pays off, investors may be provided immediate access to 
this information rather than waiting until the next MBS reporting cycle. 

[0069] In the illustrated embodiment, the servicer and investor reporting 
logic 30 and the securitization logic 32 utilize the same data base (see Fig. 4). 
As a result, the data used by the securitization logic 32 is always synchronized 
with the data used by the servicer and investor reporting logic 30. Thus, it is 
not necessary for the securitization logic 32 to wait until the end of a periodic 
(e.g., monthly) reporting cycle to receive updated data, but rather the 
securitization logic 32 always has access to up-to-date loan information. In 
another embodiment, the servicer and investor reporting logic 30 and the 
securitization logic 32 may utilize different data bases that are synchronized on 
a weekly basis, on a daily basis, on a sub-daily basis, or in real time, depending 
on the frequency of update that is desired. 
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[0070] A servicing transfer logic 142 facilitates the process of transferring 
loans for the servicing rights of owned or securitized mortgages from one 
servicer to another or from one portfolio to another within the same servicer as 
of an effective date. A servicing transfer may be initiated, for example, if a 
servicer decides to stop servicing loans for business reasons, if a servicer 
decides to transfer a certain group of loans to another branch or portfolio, if a 
servicer is involved in a merger or acquisition of the servicer necessitating a 
transfer to the surviving entity, or for other reasons. The servicing logic 142 
processes information regarding the old and new servicers and the loans that 
are subject to the change in servicing and updates loan record data for the 
respective affected loans. The effective date of the change in servicing is also 
specified. Information that is provided to the servicing transfer logic 142 as 
part of a servicing request includes the transferors servicer number, address 
and contact information, the transferees servicer number, address and contact 
information, unique loan numbers to be transferred, effective date, and other 
data. Additional steps, such as notifying the transferor of the termination and 
assessing transfer fees may also be performed. 

[0071] The cash processor 144 provides a facility to allow servicers and 
other vendors to create and maintain bank account information. The accounts 
are bank accounts established with the purchaser to facilitate loan 
transactions. Servicers have the ability to create/select/update their account 
information in real time, including account numbers and 

remittance/disbursement information. The information captured in this process 
allows the cash processor 1 44 to create and execute Automated Clearing 
House (ACH) transactions. Historical records of servicers and vendors account 
and draft information is maintained to assist in resolving any issues that may 
arise. 

[0072] Additionally, the cash processor 144 retrieves remittance and 
disbursement information from other areas of the data processing system 12. 
The remittance and disbursement information includes effective date, loan 
number, dollar amount, remittance code, and granular level details. The cash 
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processor 144 performs a rollup of loan level details by servicer number as 
required. The cash processor 144 also performs a rollup of loan level details 
by seller number whenever the seller is not the designated servicer. The cash 
processor 1 44 triggers appropriate accounting transaction codes as needed 
that allow the book and tax accounting processor 146 to record applicable 
accounting entries. 

[0073] Finally, the cash processor 144 creates cash transactions, for 
example, automated clearing house (ACH) transactions, outgoing check 
transactions, and so on. The cash processor 140 begins this process after the 
cash processor 144 has completed the process of assessing and validating 
remittance and disbursement data. The first step in creating a cash transaction 
is validating servicer/vendor bank account information. Ultimately, an ACH 
transaction is created that debits or credits the appropriate custodial bank 
account. 

[0074] The book and tax accounting logic 146 manages accounting activities 
associated with the loans. The accounting logic 146 provides a consistent 
methodology for the recording of accounting events related to mortgage 
business activities across the acquisition logic 28 and the servicer and investor 
reporting logic 30 into subsidiary ledgers for posting to a general ledger. The 
book and tax accounting logic 146 supports the accounting activities related to 
the packaging of loan cash flows to the first level packet for the securitization 
logic 32. In addition, the book and tax accounting logic 146 supports the 
accounting activities related to forming securities or packets out of portfolio 
loan collateral. The investment accounting for securities held in portfolio and 
for the payment distribution on mortgage derivatives could also be handled by 
the book and tax accounting logic 146 or, preferably, is handled by separate 
accounting logic 1 56, described in greater detail below. 

[0075] The book and tax accounting logic 146 journalizes mortgage related 
business activity, maintains subsidiary ledgers, provides audit trails, provides 
data integrity and control within the subsidiary ledgers, facilitates timely 
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reconciliations, provides flexibility to account for new products or changes 
depending on actual accounting methodologies, and provides information 
needed to perform financial analysis. In one embodiment, the book and tax 
accounting logic 1 46 utilizes an accounting matrix which is a two-dimensional 
structure comprised of accounting "families" and "family members/ 7 The 
families are groups of accounting relevant transaction and loan attributes, and 
the family members are the allowable values for each of the groups. All 
intersections of families and family members have a debit and credit account 
number associated with each of the intersections. When the journal entry is 
created, the appropriate debit and credit account numbers are first assigned to 
each of the transactions as they are processed. The accounting matrix uses 
business rules processor 180 to automatically interpret the transactions. As 
new products are introduced, the accounting matrix is modified to incorporate 
new family and/or family members to properly record the new business 
activity. Similarly, as products become obsolete, or as the requirement for 
breaking out activity on the corporate general ledger becomes less detailed, the 
accounting matrix can be modified to adapt to those changes as well. 

[0076] As business activities are processed, they are recorded/journalized in 
a subsidiary ledger according to the debit and credit account numbers assigned 
from the accounting matrix. This occurs by translating business activities into 
family and family member transactions that can be interpreted by the matrix. 
A subsidiary ledger provides the capability to view the lowest level of business 
activity that created the entry in the subsidiary ledger to maintain an audit trail 
for the subsidiary ledger activity. As activity is recorded, a system walk 
forward test of the subsidiary ledger balances is also performed to assure data 
integrity with the subsidiary ledger. At the end of accounting cycles, activity 
within the subsidiary ledgers is automatically summarized and posted to the 
general ledger. 

[0077] At the end of the accounting cycle, reconciliation is performed 
between the subsidiary ledger activity and balances, and the general ledger 
activity and balances using an automated reconciliation tool. An automated 
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reconciliation tool may be provided that generates the results of the 
reconciliation and, through a user interface, displays the results to an operator. 
Any reconciling items between the subsidiary and general ledgers may be 
analyzed and resolved by the operator. Through the operator interface, the 
operator updates the status of the reconciling items to indicate the results of 
the analysis. As reconciling items are resolved, the operator triggers the 
automated reconciliation facility to repeat the reconciliation and display the 
results. 

[0078] The book and tax accounting logic 146 also provides information for 
financial and operational analysis. Information related to the status of the book 
and tax accounting logic is provided to operations through an accounting 
console. The accounting console is a management and operational workflow 
tool that includes notifications and status information related to the book and 
tax accounting processes. It also provides summarized reports and the ability 
to view the detailed information supporting those reports. 

[0079] A preferred implementation of the securitization logic 32 and 
subcomponents thereof will now be described. The securitization logic 32 
includes sifting/sorting logic 1 52 which accesses inventory, identifies collateral 
or asset attributes and sub-attributes, and categorizes data at its most granular 
level in both aggregating and segregating cash flows associated with mortgage 
assets. The sifting/sorting logic 152 provides a ijser interactive application 
that allows users to define selection criteria (loan and/or atomic 
characteristics), prioritize them, evaluate results, and make decisions about 
market transactions and their related economics. By sifting and sorting 
through available inventories, cash flows may be qualified and quantified for 
optimal aggregation of targeted transactions, given relative market value. The 
sifting/sorting logic 1 52 operates under a user maintainable library of business 
rules associated with mortgage instruments and respective cash flows. An 
auto sift function is also provided to allow to batch processing of predefined 
inventory types. For example, a daily auto sift may be executed against 
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"available for sale" loans to aggregate and pre-packet the loans for future 
transactions. 

[0080] The purpose of the sifting/sorting logic 1 52 is to provide a 
mechanism by which users can examine the entire collateral universe and pair 
down to smaller groupings of collateral or assets within the universe. 
Collateral refers to any cash flow derived from loans, pools, securities, 
commitments, and packets. The purpose of sorting is to group the subset of 
collateral identified in the sifting process and organize it by a single or multiple 
attributes to further refine the pool of candidate collateral to be placed into a 
potential packet. The sifting/sorting logic 1 52 supports the packeting logic 
1 54, described below. 

[0081] The packeting logic 154 is used to create, maintain, and otherwise 
support packets. A packet is an aggregation or packaging of cash flows that 
is treated as an entity separate and distinct from the incoming cash flows that 
support the packet and from the cash flows that result from the packet. 
Packets maintain the data integrity of the underlying assets as received by the 
LPC logic 102 and create an information chain that maps to a higher-order 
asset (e.g., an MBS or other financial instrument to be sold to an investor). 
The source data for packets may be loan-level or packet-level information, and 
the packets themselves may represent actual securities or just a unit of 
reporting and remittance. 

[0082] Packets permit the data processing system 12 to enable and support 
new transactions by providing a platform for sourcing, normalizing, and 
centralizing cash flow-related data and building the linkages between loan 
assets and securities or non-securitized assets. Packets provide greater 
flexibility in the transformation of cash flows from the primary mortgage/loan 
level to the secondary market and within the secondary market. Packets 
provide the flexibility not only to create and sell securities to investors but also 
to support non-securitized forms of packaging to enable selling or retaining 
cash flows from individual loans. The ability to create and manipulate packets 
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enables the creation of new types of financial instruments and new types of 
transactions within the secondary market. 

[0083] Figure 5 depicts a sample data map from a lender reported inbound 
record, through re-map, to packets. In the example of Fig. 5, a loan acquired 
on a cash basis has a portion of its cash flows re-mapped, and some of those 
cash flows participate in two packets, one an out-of-Portfolio MBS pool, the 
other an excess servicing fee strip. In this arrangement, the incoming data and 
cash flows is decoupled from the outgoing data and cash flows. This 
separation allows the timing and collection of cash flows from servicers to be 
treated independently from timing of payments to investors. This is useful in 
the case of structured transactions. 

[0084] Packets preferably store the following four categories of data: packet 
header information (creation, purpose, and transaction information); cash flow 
and disclosure uses (data map); periodic process instructions and information; 
output requirements information. Thus, a packet stores information about its 
own attributes, the disposition of its cash flows, and any reported output, 
including disclosure data. Additionally, a packet stores information that 
describes its behavior, which may be derived from external business rules. 
These business rules may be standard (as in the case of MBS packets), or they 
may apply to a specific packet (as in the case of a structured transaction). 
Packet data fields may be added or changed to support new products. 

[0085] In some cases, it may be necessary to apply data decomposition (or 
"internal re-mapping") to lender reported data. Some of the data 
decomposition steps may precede packet creation and rollup, converting loan 
level data reported by lenders into a form useful to downstream processes. In 
cases where the internal use of lender reported inbound data is differs from its 
use within a packet, data re-mapping is also required for roll-up. 

[0086] The accounting logic 1 56 supports additional accounting functions 
for the securitization logic 32 that are not already supported by the book and 
tax accounting processor 146. In general, the book and tax accounting 
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processor 146 is responsible for performing maintenance accounting at the 
loan level (i.e., posting transactions), while the accounting logic 156 is 
responsible for the accounting logic associated with transformative accounting 
events. Transformative accounting events include, for example, securitization 
events (in which a loan is to be construed to be sold). Other transformative 
events include a securitization event in which only a portion of the cash flows 
are sold, a sale event of a portfolio securities, and a sale event involving a 
whole loan. In addition, the accounting logic 1 56 is responsible for ongoing 
maintenance in connection with the reconciliation of securities cash payables. 
The accounting logic 1 56 performs such things as deriving the initial cost basis 
at the time of acquisition for every loan and inventory, maintaining the cost 
basis of each loan, tracking accounting intent for each loan, and performing 
market valuation for each loan. Of course, although the functionality of blocks 
146 and 156 are shown as being conceptually separate, this functionality 
could also be combined. 

[0087] The position monitor 1 58 allows monitoring of the purchaser's overall 
trade and investment position. Particularly, the position monitor 158 is an 
interactive tool that is usable to monitor positions of investors of whole loans 
and securities, and designate or redesignate inventory between trading 
accounts. The position monitor 158 is able to provide this information in near 
real time because the position monitor 1 58 either uses the same transactional 
database(s) as the servicer and investor reporting logic 30 and the 
securitization logic 1 32 or, preferably, uses a separate data base that is 
synchronized with these data bases. For both whole loans and securities, the 
position monitor 1 58 provides daily and month-to-date commitment/trade and 
delivery/settlement positions. The position monitor 158 also provides 
cumulative inventory positions held by the portfolio. The position monitor 158 
allows investors to manage inventory from an economic, risk management, and 
regulatory accounting and taxation perspective. It also allows investors to 
determine or designate what assets to buy, what assets to sell, and what 
assets to retain or hold for investment. The portfolio manager 1 58 provides 
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investors with a clear and concise view of their current net position of 
inventory. 

[0088] The out of portfolio (OOP) pooling logic 1 60 permits the data 
processing system 1 2 to be used for pooling loans to create financial 
instruments in situations where the loans are owned by the entity that owns or 
operates the data processing system 1 2 or by an entity other than the entity 
that owns/operates the data processing system 12. The OOP pooling logic 
1 60 provides the owner of the loans being pooled with the ability to select 
asset attributes and sub-attributes at a granular level, the ability to select loans 
to optimize chartered pool statistics, the ability to flexibly map incoming and 
outgoing cash flows, and the ability to use an on-screen display to manipulate 
collateral. The out of portfolio pooling processor 1 60 also has the ability to 
collateralize asset cash flows as described above in connection with the 
packeting logic 154. 

[0089] The whole loan trading logic 162 provides a facility for engaging in 
whole loan trades to permit the owner or operator of the data processing 
system 1 2 to identify and sell loans out of its portfolio to other entities. The 
whole loan trading logic 1 62 also provides logic for reporting to the servicer of 
a sold loan (1) that the loan has been sold and (2) the identity of the new 
owner of the loan, allowing the servicer to begin reporting payment information 
to the new owner. 

[0090] Referring to Fig. 4, the common services logic 34 includes work flow 
processor 170 which generates notifications about required actions and routes 
the notifications to users of the data processing system 1 2 according to 
pre-defined processing sequences for request approvals and exception report 
resolutions. The work flow processor 170 also keeps track of status and 
actions related to work items. 

[0091] The report processor 172 generates reports based on users' requests. 
The report processor 1 72 allows data to be extracted from the data bases to 
prepare reports that can be sent out through the user services logic 22. The 
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reports that are returned may be bulk transfers of data. The, report processor 
172 supports generating the reports described above in connection with the 
acquisition logic 28, the servicer and investor reporting logic 30, and the 
securitization logic 32. 

[0092] The database and access control logic 1 74 provides database and 
user security administration and control for the databases in the data storage 
system 38 and functions available through system 1 2. The database access 
and control logic also maintains referential integrity, processes queries and 
updates, and performs all tasks related to access and control of the databases 
in the data storage system 38. 

[0093] The process controller/scheduler 176 triggers execution of processes 
based on time schedule and/or events received from application components. 
The process controller/scheduler encapsulates information on processing 
interdependencies between different components in the data processing 
system 1 2. 

[0094] The audit logging logic 1 78 logs data that is needed for historical 
tracking of the activities of the data processing system 1 2. The purpose of the 
data logging is primarily to meet audit requirements in connection with the 
transactions processed by the data processing system 12. 

[0095] The business rules processor 1 80 is a rules engine that encapsulates 
business rules to permit the business rules to be applied to the loan data. 
Examples of the business rules applied by the rules processor 1 80 have been 
described throughout the discussion of the data processing system 12. A user 
interface is provided that allows the business rules to be modified and that 
allows new business rules to be added or .obsolete business rules to be deleted. 
The rules processor 1 80 maintains the business rules separate from the 
remainder of the application code that implements other aspects of the data 
processing system 1 2. This allows the business rules to be 
modified/added/deleted without requiring revisions to the application code. 
The ability to modify or add business rules quickly facilitates the introduction of 
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new types of loan products and investment instruments, because the data 
processing system 1 2 may be easily modified to implement any special data 
processing required for the implementation of the new loan 
products/investment instruments. Preferably, the rules processor 180 is 
provided as three separate rules processor, one for each of the acquisition logic 
28, the servicer and investor reporting logic 30, and the securitization logic 32, 
with separate user interfaces for each rules processor. 

[0096] As previously indicated, service granularity is achieved in part by 
representing loans as a series of data attributes. The following is an example 
of a set of attributes that may be used to characterize loans: accounting class 
code; accounting close effective period; accounting reporting category code; 
actual UPB at acquisition; adjusted last paid installment date; adjusted unpaid 
principal balance; ceiling; change frequency; change method; conduit code; 
custodian code; downward cap; downward cap code; effective date; excess 
yield; excess yield adjustment; extended term; purchaser loan number; final 
step change; first PITI (principal, interest, taxes, insurance) due date; fixed 
interest rate; fixed pass-thru rate; fixed payment amount; floor; frequency of 
payment change; frequency of rate change; future feature code; index code; 
index lookback; interest rate; loan guaranty payment date; loan conversion 
date; loan guaranty date; loan payoff interest calculation code; loan rate 
effective date; loan to value ratio; LP control record; lender pass through (LPT) 
type code; maximum term; months payment control effective; months rate 
control effective; mortgage margin; mortgage term; net interest adjustment; 
new payment amount; next control record; next scheduled payment change 
date; next scheduled rate change date; number of months in effect; other fees 
collected adjustment; pass-thru rate; payment change amount/percentage; 
payment change method code; payment control record; payment type code; 
principal adjustment; processing status code; product code; rate change 
method code; rate change percent; rate control record; rate conversion status 
code; rate rounding method; rate type code; reclassification date; remittance 
day code; required change index; required margin; secured unpaid principal 
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balance; servicing fee; servicing fee adjustment; servicing fee type; servicing 
remittance option; unpaid principal balance; upward cap; upward cap code. In 
addition to the above-mentioned attributes, additional attributes may be used in 
connection with particular types of specialty loan products. 

[0097] As previously indicated, data granularity is achieved at least in part 
by decomposing loan assets into a series of cash flows. A cash flow may be 
any type of payment, whether of principal, interest, or fees. Cash flow may 
also includes credit-related losses, which manifest themselves from the 
securities standpoint as negative investor payments (i.e., a reduction to 
positive cash flows). Possible sources of cash flow may be associated with 
principal, interest, servicing fees, guarantee fees, mortgage insurance, 
prepayment penalties, borrower-paid fees, servicer advances, servicer 
recoveries, loss/default components, and REO activity. For principal, individual 
cash flows that may be identified include the following: scheduled principal 
(amount payable based on scheduled amortization), actual principal (what was 
applied as principal), unscheduled principal (amount from borrower applied in 
excess of scheduled), advanced (amount not collected from borrower but 
remitted to investor), shortfall (underpayment from borrower, usually meaning 
less than full scheduled amount). For interest, individual cash flows that may 
be identified include the following: scheduled Interest (amount payable), actual 
(what was applied), excess (interest collection in excess of amount payable), 
advanced (not collected from borrower but sent to investor), shortfall 
(underpayment from servicer), capitalized (negative amortization), other 
capitalized interest (delinquency), unrecoverable prepayment interest shortfall. 
For servicing fees, individual cash flows that may be identified include the 
following: gross servicing fee, core servicing fee (usually relates to tax), 
excess servicing fee, safe harbor (tax). For guarantee fees, individual cash 
flows that may be identified include the following cash flows: gross guarantee 
fee (GF) (total charged to the lender), cash flows for internally tracking costs 
(e.g., costs associated with credit risk), base GF, GF variance , and other GF 
adjustments. For mortgage insurance (Ml), individual cash flows that may be 
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identified include the following: lender paid Ml, borrower paid Ml, portion of 
GF construed to be Ml, back-end Ml. For prepayment penalties, individual cash 
flows that may be identified include the following: prepayment penalty, 
prepayment penalty (borrower-paid), yield maintenance fee (borrower-paid). 
For borrower-paid fees, individual cash flows that may be identified include the 
following: borrower-paid fees, late payment fee, conversion/modification fee. 
For seller advances, individual cash flows that may be identified include the 
following: advanced principal, advanced interest, advanced guaranty fee, 
servicing advances (usually relates to defaults, e.g., T&l). For servicer 
recoveries, individual cash flows that may be identified include the following: 
recovered principal advances, recovered interest advances, recovered guaranty 
fee advances, recovered servicing advances. For default activity, cash flows 
that may be identified include the following: net realized loss (total amount 
payable to investors less all recoveries), foreclosure expenses, attorney fees, 
recoup of non-recoverable advances, loss due to modification, loss due to 
appraisal reduction, loss due to deficiency valuation, non-capitalized deferred 
interest (e.g. workout), interest paid on advances. For REO activity, cash 
flows that may be identified include the following: foreclosure sale proceeds, 
rental income, insurance proceeds, tax expenses on REO, repair expenses on 
REO, sale/marketing expenses on REO, REO property maintenance expenses. It 
may be rioted that some of the above cash flows are aggregate cash flows 
that can be further decomposed. Other cash flow pertinent information that 
may be tracked includes unpaid principal balance (UPB) (including scheduled 
UPB and actual UPB), participation percentage (including principal participation 
percentage, interest participation percentage, and servicing fee participation 
(basis points)), discount rate (used to calculate yield maintenance or 
prepayment penalty), appraised balance, foreclosure sale date, and REO sale 
date. 

[0098] Many other changes and modifications may be made to the present 
invention without departing from the spirit thereof. The scope of these and 
other changes will become apparent from the appended claims. 
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WHAT IS CLAIMED IS: 

1 . A data processing system for processing loan information, 
comprising: 

acquisition logic, the acquisition logic including logic configured to 
receive acquisition information pertaining to loan term, interest rate, principal 
owed and other parameters for a plurality of loans; 

reporting logic, the reporting logic including logic configured to receive 
payment reporting information regarding borrower payments in connection with 
the plurality of loans, perform loan accounting in connection with the borrower 
payments, and generate accounting output, the reporting information being 
received on an ongoing basis throughout at least a portion of a term of each 
the plurality of loans; 

financial asset generation logic, the financial asset generation logic 
including logic configured to facilitate creation and maintenance of a plurality 
of financial assets backed by the plurality of loans, the creation and 
maintenance of the plurality of financial assets resulting in the generation of 
investment information; and 

a rules engine, the rules engine comprising a series of business rules; 

and 

wherein the loan information includes the acquisition information, the 
reporting information, and the investment information, and wherein the rules 
engine processes the loan information by applying the business rules to the 
loan information. 

2. A data processing system according to claim 1 , wherein the 
acquisition logic, the reporting logic, the financial asset generation logic, and 
the rules engine are provided on a common integrated data processing 
platform. 

3. A data processing system according to claim 1, further comprising 
a common data storage system, the data storage system being commonly 
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accessible to the acquisition logic, the reporting logic, and the financial asset 
generation logic. 

4. A data processing system according to claim 3, wherein the data 
storage system comprises at least two data bases, wherein the at least two 
data bases are accessible by different portions of the acquisition logic, the 
reporting logic, and the financial asset generation logic, and wherein the at 
least two data bases are synchronized on at least approximately a weekly 
basis. 

5. A data processing system according to claim 3, wherein the data 
storage system comprises at least two data bases, wherein the at least two 
data bases are accessible by different portions of the acquisition logic, the 
reporting logic, and the financial asset generation logic, and wherein the at 
least two data bases are synchronized on at least approximately a daily basis. 

6. A data processing system according to claim 1, wherein the rules 
engine comprises a plurality of rules engines separately provided with the 
acquisition logic, the reporting logic, and the financial asset generation logic. 

7. A data processing system according to claim 1, wherein each of 
the plurality of loans is described using a series of attributes, and wherein the 
data processing system is capable of being modified to process loan 
information for new types of loans by modifying the composition of the series 
of attributes. 

8. A data processing system according to claim 1, wherein the data 
processing system decomposes the plurality of loans into a plurality of assets 
represented by a plurality of cash flows, the plurality of cash flows includes a 
plurality of cash flows pertaining to principal payments, a plurality of cash 
flows pertaining to interest payments, a plurality of cash flows pertaining to 
servicing fees, and a plurality of cash flows relating to other borrower 
payments. 
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9. A data processing system according to claim 8, wherein the data 
processing system includes a cash flow mapping system, the cash flow 
mapping system permitting outgoing cash flows associated with the plurality of 
financial assets to be traced back to individual cash flows associated with 
specific ones of the plurality of loans. 

10. A data processing system according to claim 9, wherein the 
plurality of financial assets generated by the financial asset generation logic 
includes a packet used by the cash flow mapping system. 

11. A data processing system according to claim 8, wherein the data 
processing system decomposes each of the plurality of loans such that the 
plurality of cash flows represent substantially all possible sources of cash flow 
associated with the plurality of loans. 

1 2. A data processing system according to claim 8, wherein the 
plurality of cash flows include negative cash flows. 

13. A data processing system according to claim 1, wherein the 
plurality of financial assets generated by the financial asset generation logic 
includes a mortgage backed security backed by the plurality of loans. 

14. A data processing system according to claim 1 3, wherein the 
investment information includes financial performance information regarding 
the mortgage backed security. 

1 5. A data processing system according to claim 14, wherein the data 
processing system includes logic configured to determine a guarantee fee, the 
guarantee fee being a fee for guaranteeing timely payment of the plurality of 
loans that back the mortgage backed security. 

16. A data processing system according to claim 1 , wherein the 
financial asset generation logic includes a portfolio monitor, the portfolio 
monitor being capable of monitoring financial performance of the plurality of 
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loans in substantially real time as the information regarding borrower payments 
is received. 

17. A data processing system according to claim 1, wherein the 
reporting logic is configured to receive the information regarding borrower 
payments on a sub-monthly basis. 

1 8. A data processing system according to claim 1 , wherein the 
reporting logic is configured to receive the information regarding borrower 
payments on approximately a daily basis. 

1 9. A data processing system according to claim 1 , wherein the 
reporting logic is configured to receive the information regarding borrower 
payments in approximately real time. 

20. A data processing system comprising: 

acquisition logic, the acquisition logic including logic configured to 
receive information pertaining to loan term, interest rate, principal owed and 
other parameters for a plurality of loans; 

reporting logic, the reporting logic including logic configured to receive 
payment information regarding borrower payments in connection with the 
plurality of loans, perform loan accounting in connection with the borrower 
payments, and generate accounting output, the payment information being 
received on an ongoing basis throughout at least a portion of a term of each 
the plurality of loans; 

financial asset generation logic, the financial asset generation logic 
including logic configured to facilitate creation and maintenance of a plurality 
of financial assets backed by the plurality of loans; and 

wherein the acquisition logic, the reporting logic, and the financial asset 
generation logic are provided on a common integrated data processing 
platform. 

21 . A data processing system according to claim 20, further 
comprising a common data storage system, the data storage system being 
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commonly accessible to the acquisition logic, the reporting logic, and the 
financial asset generation logic. 

22. A data processing system according to claim 21, wherein the data 
storage system comprises at least two data bases, wherein the at least two 
data bases are accessible by different portions of the acquisition logic, the 
reporting logic, and the financial asset generation logic, and wherein the at 
least two data bases are synchronized on at least approximately a weekly 
basis. 

23. A data processing system according to claim 21, wherein the data 
storage system comprises at least two data bases, wherein the at least two 
data bases are accessible by different portions of the acquisition logic, the 
reporting logic, and the financial asset generation logic,, and wherein the at 
least two data bases are synchronized on at least approximately a daily basis. 

24. A data processing system according to claim 20, 

wherein the system further comprises a process controller, the process 
controller being coupled to the acquisition logic, the reporting logic, and the 
financial asset generation logic; 

wherein the payment information is cash flow information, and the cash 
flow information further comprises information pertaining to payments made to 
holders of the financial assets backed by the plurality of loans; and 

wherein the process controller has embedded therein information on 
processing interdependences between the acquisition logic, the reporting logic, 
and the financial asset generation logic, the process controller using the . 
embedded information to control processing of the cash flow information by 
the reporting logic and the financial asset generation logic. 

25. A data processing system according to claim 20, further 
comprising an Internet-enabled user interface, the Internet-enabled user 
interface permitting a user to access the data processing system by way of the 
Internet or an Intranet. 
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26. A data processing system according to claim 20, wherein the 
acquisition logic further comprises 

committing logic configured to permit a seller of the plurality of loans to 
enter into a commitment to sell the loans, 

pricing logic configured to determine selling prices for the plurality of 
loans, and 

deal management logic configured to track terms of deals entered into 
with a seller of the plurality of loans. 

27. A data processing system according to claim 26, wherein the 
reporting logic further comprises 

comparison logic configured to calculate expected payment information 
pertaining to the plurality of loans and to compare the expected payment 
information with the received payment information, 

accounting logic configured to generate accounting records reflecting the 
received payment information, and 

aggregation logic configured to aggregate cash flows from the plurality 
of loans to generate payment information for the plurality of financial assets. 

28. A data processing system according to claim 27, wherein the 
financial asset generation logic further comprises portfolio monitor logic 
configured to monitor real time financial status of the plurality of financial 
assets. 

29. A data processing system according to claim 20, further 
comprising stored cash flow maps, the cash flow maps comprising information 
that defines cash flows reported in the reporting information map to cash flows 
described in the investment information. 

30. A data processing system according to claim 29, wherein the 
plurality of financial assets generated by the financial asset generation logic 
includes a packet used by the cash flow mapping system. 
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31 . A data processing system according to claim 20, wherein the 
plurality of financial assets generated by the financial asset generation logic 
includes a mortgage backed security backed by the plurality of loans. 

32. A data processing system according to claim 31, wherein the 
investment information includes financial performance information regarding 
the mortgage backed security. 

33. A data processing system according to claim 32, wherein the data 
processing system includes logic configured to determine a guarantee fee, the 
guarantee fee being a fee for guaranteeing timely payment of the plurality of 
loans that back the mortgage backed security. 

34. A data processing system according to claim 20, wherein the 
reporting logic is configured to receive the information regarding borrower 
payments on a sub-monthly basis. 

35. A data processing system according to claim 20, wherein the 
reporting logic is configured to receive the information regarding borrower 
payments on approximately a daily basis. 

36. A data processing system according to claim 20, wherein the 
reporting logic is configured to receive the information regarding borrower 
payments in approximately real time. 

37. A data processing system comprising: 

(A) acquisition logic, the acquisition logic including logic configured to 
receive acquisition information pertaining to loan term, interest rate, principal 
owed and other parameters for a plurality of loans, the acquisition logic 
including 

(1) committing logic configured to permit a seller of the 
plurality of loans to enter into a commitment to sell the loans, 

(2) pricing logic configured to determine selling prices from the 
plurality of loans, and 
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(3) deal management logic configured to track terms of deals 
entered into with the seller of the plurality of loans; 

(B) reporting logic, the reporting logic including logic configured to 
receive payment reporting information regarding borrower payments in 
connection with the plurality of loans, the reporting information being received 
on an ongoing basis throughout at least a portion of a term of each the 
plurality of loans, the reporting logic including 1 

(1) comparison logic configured to calculate expected payment 
reporting information pertaining to the plurality of loans and to compare 
the expected payment reporting information with the received payment 
information, 

(2) accounting logic configured to generate accounting records 
reflecting the received payment information, and 

(3) aggregation logic configured to aggregate cash flows from 
the plurality of loans to generate payment information for the plurality of 
financial assets. 

(C) financial asset generation logic, the financial asset generation logic 
including logic configured to facilitate creation and maintenance of a plurality 
of financial assets backed by the plurality of loans, the creation and 
maintenance of the plurality of financial assets resulting in the generation of 
investment information; and 

(D) a rules engine, the rules engine comprising a series of business 

rules; 

(E) a common data storage system, the data storage system being 
commonly accessible to the acquisition logic, the reporting logic, and the 
financial asset generation logic; 

wherein the loan information includes the acquisition information, the 
payment reporting information, and the investment information, and wherein 
the rules engine processes the loan information by applying the business rules 
to the loan information; and 
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wherein the acquisition logic, the reporting logic, and the financial asset 
generation logic are provided on a common integrated data processing 
platform. 

38. A data processing system according to claim 37, wherein the data 
storage system comprises a first data base accessible to the reporting logic and 
a second data base accessible to the financial asset generation logic, and 
wherein the first and second data bases are synchronized on at least 
approximately a weekly basis. 

39. A data processing system according to claim 37, wherein the data 
storage system comprises a first data base accessible to the reporting logic and 
a second data base accessible to the financial asset generation logic, and 
wherein the first and second data bases are synchronized on at least 
approximately a daily basis. 

40. A data processing system according to claim 37, wherein each of 
the plurality of loans is described using a series of attributes, and wherein the 
data processing system is capable of being modified to process loan 
information for new types of loans by modifying the composition of the series 
of attributes. 

41 . A data processing system according to claim 37, wherein the data 
processing system decomposes the plurality of loans into a plurality of assets 
represented by a plurality of cash flows, the plurality of cash flows includes a 
plurality of cash flows pertaining to principal payments, a plurality of cash 
flows pertaining to interest payments, a plurality of cash flows pertaining to 
servicing fees, and a plurality of cash flows relating to other borrower 
payments. 

42. A data processing system according to claim 41, wherein the data 
processing system includes a cash flow mapping system, the cash flow 
mapping system permitting outgoing cash flows associated with the plurality of 
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financial assets to be traced back to individual cash flows associated with 
specific ones of the plurality of loans. 

43. A data processing system according to claim 42, wherein the 
plurality of financial assets generated by the financial asset generation logic 
includes a packet used by the cash flow mapping system. 

44. A data processing system according to claim 41, wherein the data 
processing system decomposes each loan such that the plurality of cash flows 
represent substantially all possible sources of cash flow associated with the 
plurality of loans. 

45. A data processing system according to claim 41, wherein the 
plurality of cash flows include negative cash flows. 

46. A data processing system according to claim 37, wherein the 
plurality of financial assets generated by the financial asset generation logic 
includes a mortgage backed security backed by the plurality of loans. 

47. A data processing system according to claim 46, wherein the 
investment information includes financial performance information regarding 
the mortgage backed security. 

48. A data processing system according to claim 47, wherein the data 
processing system includes logic configured to determine a guarantee fee, the 
guarantee fee being a fee for guaranteeing timely payment of the plurality of 
loans that back the mortgage backed security. 

49. A data processing system according to claim 37, wherein the 
reporting logic is configured to receive the information regarding borrower 
payments on a sub-monthly basis. 

50. A data processing system according to claim 37, wherein the 
reporting logic is configured to receive the information regarding borrower 
payments on approximately a daily basis. 
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51 . A data processing system according to claim 37, wherein the 
reporting logic is configured to receive the information regarding borrower 
payments in approximately real time. 

52. A data processing system comprising: 

acquisition logic, the acquisition logic including logic configured to 
receive information pertaining to loan term, interest rate, principal owed and 
other parameters for a plurality of loans; 

reporting logic, the reporting logic including logic configured to receive 
payment information regarding borrower payments in connection with the 
plurality of loans, perform loan accounting in connection with the borrower 
payments, and generate accounting output, the payment information being 
received on an ongoing basis throughout at least a portion of a term of each 
the plurality of loans; 

loan process and compare logic, the loan process and compare logic 
including logic configured to monitor and validate information and activities 
regarding the plurality of loans; and 

wherein the acquisition logic, the reporting logic, and the loan process 
and compare logic are provided on a common integrated data processing 
platform. 

53. A data processing system according to claim 52, wherein the loan 
process and compare logic is configured to receive and validate information 
generated by the reporting logic. 

54. A data processing system according to claim 53, wherein 
validating information and activities regarding the plurality of loans includes 
comparing data received from the reporting logic to data received from the 
acquisition logic for each of the plurality of loans. 

55. A data processing system according to claim 52, 

wherein the system further comprises a process controller, the process 
controller being coupled to the acquisition logic, the reporting logic, and the 
loan process and compare logic; 
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wherein the payment information is cash flow information, and the cash 
flow information further comprises information pertaining to payments made to 
holders of the financial assets backed by the plurality of loans; and 

wherein the process controller has embedded therein information on 
processing interdependencies between the acquisition logic, the reporting logic, 
and the loan process and compare logic, the process controller using the 
embedded information to control processing of the cash flow information by 
the reporting logic and supply information for analysis to the loan process and 
compare logic. 

56. A data processing system according to claim 52, further 
comprising an Internet-enabled user interface, the Internet-enabled user 
interface permitting a user to access the data processing system by way of the 
Internet or an Intranet. 

57. A method of processing data in connection with a plurality of 
loans, the method comprising: 

receiving payment reporting information regarding borrower payments in 
connection with the plurality of loans, the reporting information being received 
from a servicer; 

performing loan accounting in connection with the borrower payments to 
generate accounting output; 

providing an interactive tool accessible to the servicer by way of a 
network that allows the servicer to obtain access to information regarding the 
accounting output. 

58. A method according to claim 57, wherein the interactive tool is 
accessible to the servicer by way of the Internet. 
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